4장. 하드웨어별 모델 선택 전략

4.1 8GB RAM 노트북에서 가능한 수준

8GB RAM 노트북에서도 로컬 AI를 아예 못 쓰는 것은 아닙니다. 다만 2026년 5월 현재 기대치를 많이 낮춰야 합니다. 운영체제, 브라우저, IDE가 이미 상당한 메모리를 사용하므로 모델에 줄 수 있는 여유가 많지 않습니다. LM Studio 공식 시스템 요구사항에서도 8GB Mac에서는 사용할 수는 있어도 작은 모델과 적당한 컨텍스트를 권장하는 취지로 안내합니다.

이 환경에서는 1B급 소형 모델이나 매우 낮은 양자화 모델을 우선 고려하는 것이 좋습니다. 자동완성, 짧은 코드 설명, 작은 함수 생성 정도가 현실적인 목표입니다. 긴 파일 전체 리팩터링이나 프로젝트 단위 분석은 시도하지 않는 것이 좋습니다. 컨텍스트 길이도 욕심내지 않는 편이 좋습니다. 4K~8K 토큰 정도에서 시작하고, 느려지거나 메모리 경고가 뜨면 더 줄입니다.

실무 팁은 다른 프로그램을 최대한 줄이는 것입니다. 브라우저 탭을 많이 열어 둔 상태에서 IDE와 로컬 모델을 함께 돌리면 금방 메모리가 부족해집니다. 자동완성 전용 모델 하나만 켜고, 채팅은 필요할 때만 사용하는 방식이 낫습니다. 8GB 장비에서는 “로컬 AI 코딩 세트”보다 “가벼운 보조 기능”으로 접근해야 합니다.

[표 4-1] 8GB RAM 환경 추천 사용 범위.

4.2 16GB RAM 노트북의 현실적인 모델 선택

16GB RAM은 로컬 AI 입문에서 현실적인 최소선에 가깝습니다. LM Studio도 Windows 환경에서 최소 16GB RAM을 권장하고, macOS에서도 16GB 이상을 권장합니다. 이 정도면 7B급 양자화 모델을 실험할 수 있고, 자동완성과 채팅을 나누어 구성하는 것도 가능합니다.

다만 16GB RAM에서도 여유가 많은 것은 아닙니다. 7B 모델을 Q4 계열로 실행하고, 컨텍스트를 적당히 잡는 구성이 현실적입니다. 13B 이상 모델은 실행은 되더라도 느리거나 다른 작업에 영향을 줄 가능성이 큽니다. IDE, 브라우저, Docker, 데이터베이스를 함께 띄우는 개발 환경에서는 체감 메모리가 더 줄어듭니다.

16GB 환경에서 추천하는 전략은 “작은 자동완성 모델 + 중간 크기 채팅 모델”입니다. 자동완성은 1.5B~3B급 코딩 모델로 빠르게 두고, 채팅이나 리팩터링은 7B급 모델로 처리합니다. 두 모델을 동시에 메모리에 올리기 어렵다면 작업에 따라 번갈아 로드합니다.

4.3 32GB RAM Mac/Windows 개발자의 추천 구성

32GB RAM은 로컬 코딩 워크플로를 꽤 편하게 실험할 수 있는 구간입니다. 7B~14B급 모델을 보다 안정적으로 사용할 수 있고, 컨텍스트도 조금 더 넉넉하게 잡을 수 있습니다. Apple Silicon 32GB 장비라면 MLX 모델도 좋은 선택지가 될 수 있고, NVIDIA GPU가 있는 Windows/Linux 장비라면 VRAM 크기에 따라 더 빠른 구성이 가능합니다.

이 환경에서는 자동완성, 채팅, 리팩터링을 역할별로 나누는 구성을 추천합니다. 자동완성은 빠른 소형 모델, 채팅은 7B~14B 코딩 모델, 긴 설명이나 어려운 문제는 클라우드 모델을 함께 쓰는 방식입니다. 로컬 모델 하나에 모든 것을 맡기는 것보다 체감이 좋습니다.

32GB 장비에서도 GPU가 없거나 VRAM이 적으면 속도 한계가 있습니다. RAM이 충분하다는 것은 모델을 올릴 수 있다는 뜻이지, 항상 빠르다는 뜻은 아닙니다. GPU 가속이 충분한지, 모델의 어느 정도가 GPU에 올라가는지 확인해야 합니다.

[이미지 4-1] 32GB 개발자 추천 구성도.

4.4 64GB 이상 워크스테이션에서 가능한 일

64GB 이상 장비에서는 선택지가 넓어집니다. 더 큰 모델, 더 긴 컨텍스트, 여러 모델 동시 운용을 실험할 수 있습니다. 특히 32B급 모델이나 MoE 모델을 로컬에서 테스트해 볼 여지가 생깁니다. 물론 모델 크기와 양자화 수준, GPU/VRAM 구성에 따라 속도는 크게 달라집니다.

이 구간부터는 단순히 “내가 쓰는 개인 도구”를 넘어 “팀에서 공통으로 쓸 로컬 모델 서버”를 생각할 수도 있습니다. 강한 워크스테이션 한 대에서 LM Studio나 다른 서버를 띄우고, 같은 네트워크 안의 개발자가 접근하는 방식입니다. 다만 이렇게 되면 개인 로컬 환경보다 보안과 운영 책임이 커집니다. 방화벽, 접근 권한, 로그, 모델 버전 관리가 필요합니다.

64GB 이상 장비의 장점은 실험 여유입니다. 같은 작업을 7B, 14B, 32B 모델에 던져 보고 품질과 속도를 비교할 수 있습니다. 컨텍스트 길이를 늘렸을 때 품질이 좋아지는지, 아니면 느려지기만 하는지 테스트할 수 있습니다. 이 테스트 결과는 팀의 AI 사용 정책을 만드는 데 중요한 자료가 됩니다.

4.5 NVIDIA GPU 환경과 Apple Silicon 환경의 차이

NVIDIA GPU 환경은 전용 VRAM을 중심으로 생각합니다. 모델이 VRAM에 많이 올라갈수록 빠릅니다. VRAM이 부족하면 일부를 시스템 RAM이나 CPU로 처리하게 되고 속도가 떨어질 수 있습니다. CUDA 지원과 드라이버 상태도 중요합니다. llama.cpp는 NVIDIA GPU를 위한 CUDA 커널, Apple Silicon 최적화, 여러 백엔드 지원, CPU+GPU 하이브리드 추론 등을 제공합니다.

Apple Silicon 환경은 통합 메모리 구조가 특징입니다. CPU와 GPU가 같은 메모리 풀을 공유합니다. 그래서 “VRAM 몇 GB”라고 따로 생각하는 NVIDIA 환경과 다릅니다. Apple의 MLX는 Apple Silicon의 통합 메모리 구조에 최적화된 머신러닝 프레임워크로 설명됩니다. LM Studio도 Apple Silicon Mac에서 MLX 엔진을 지원해 MLX 모델을 실행할 수 있습니다.

어느 쪽이 더 좋다고 단정하기는 어렵습니다. NVIDIA GPU는 고성능 GPU와 넓은 CUDA 생태계가 강점입니다. Apple Silicon은 노트북 폼팩터에서 통합 메모리와 전력 효율이 장점입니다. 중요한 것은 내 장비에서 실제로 어떤 모델이 얼마나 빠르게 도는지입니다. 로컬 AI는 스펙표보다 체감 테스트가 더 정확할 때가 많습니다.

[표 4-2] NVIDIA GPU와 Apple Silicon 비교.

4.6 VRAM이 부족할 때 생기는 병목

VRAM이 부족하면 여러 현상이 나타납니다. 모델 로딩이 실패할 수 있습니다. 로딩은 되지만 응답이 매우 느릴 수 있습니다. 컨텍스트를 늘릴수록 갑자기 느려지거나 중간에 멈출 수 있습니다. GPU 사용률은 낮은데 CPU와 RAM 사용량만 올라가는 경우도 있습니다.

VRAM 부족은 모델 가중치만의 문제가 아닙니다. 컨텍스트가 길어지면 KV 캐시 등 추론 중 필요한 메모리도 늘어납니다. 따라서 “모델 파일은 들어가는데 긴 컨텍스트에서 터진다”는 일이 생깁니다. LM Studio는 모델 로드 설정에서 context length와 GPU offload 같은 파라미터를 다룰 수 있으며, 공식 문서에서도 load-time parameter로 context length와 GPU offload ratio를 설명합니다.

해결 방법은 네 가지입니다. 더 작은 모델을 씁니다. 더 낮은 양자화 모델을 씁니다. 컨텍스트 길이를 줄입니다. GPU offload 설정을 조정합니다. 초보자는 먼저 모델 크기와 컨텍스트를 줄이는 것이 좋습니다. 고급 사용자는 GPU 레이어 배치나 백엔드 설정을 조정할 수 있지만, 처음부터 복잡하게 갈 필요는 없습니다.

4.7 RAM overflow가 성능에 미치는 영향

RAM이 부족하면 운영체제는 디스크를 임시 메모리처럼 쓰는 swap을 사용합니다. SSD가 빠르더라도 RAM보다 훨씬 느립니다. 로컬 모델이 swap에 의존하기 시작하면 응답 속도가 크게 떨어지고, IDE 전체가 버벅일 수 있습니다. 개발자는 모델이 느린 줄 알지만, 실제 원인은 시스템 메모리 압박일 수 있습니다.

이 문제는 특히 노트북에서 자주 발생합니다. 브라우저 탭, Docker 컨테이너, 데이터베이스, 디자인 툴, Slack, IDE를 모두 띄운 상태에서 로컬 모델까지 실행하면 메모리가 금방 찹니다. 모델이 로딩되었다고 끝이 아닙니다. 질문을 주고받으며 컨텍스트가 쌓이면 메모리 사용량이 늘어날 수 있습니다.

RAM overflow를 피하려면 작업 환경을 단순하게 유지합니다.

• 필요 없는 모델은 언로드합니다.
• 컨텍스트를 과하게 늘리지 않습니다.
• 장시간 세션 후에는 서버를 재시작해 메모리를 정리합니다.
• 작업 관리자나 Activity Monitor를 열어 실제 메모리 사용량을 확인하는 습관을 들입니다.

4.8 “쓸 수 있는 모델”과 “쾌적하게 쓸 수 있는 모델” 구분하기

로컬 AI에서 가장 중요한 구분은 “실행 가능한 모델”과 “매일 쓸 수 있는 모델”입니다. 어떤 모델은 겨우 로딩되고 답변도 나오지만, 한 번 답을 받는 데 1분이 걸릴 수 있습니다. 기술적으로는 쓸 수 있지만, 개발 흐름에서는 쓸 수 없습니다.

쾌적한 모델은 작업 리듬을 끊지 않습니다.

• 자동완성은 거의 즉시 떠야 합니다.
• 채팅은 짧은 질문에 몇 초 안에 반응해야 합니다.
• 리팩터링은 기다릴 만한 시간 안에 결과를 줘야 합니다.
• 정확도가 조금 높아도 너무 느리면 자주 쓰지 않게 됩니다.
• 자주 쓰지 않는 도구는 생산성을 높이지 못합니다.

따라서 모델 선택 테스트에는 반드시 속도 기준을 넣어야 합니다. 토큰/초 수치도 좋지만, 체감 기준이 더 중요합니다. “자동완성 제안이 입력 흐름을 방해하지 않는가”, “짧은 질문에 답을 기다릴 수 있는가”, “긴 작업을 맡길 때 다른 일을 할 정도로 오래 걸리는가”를 봅니다.

[실습 4-1] 모델 후보 3개를 같은 프롬프트로 테스트하고 표를 작성합니다.